Pay Stations
The PayStation feature is a relatively straightforward self-contained application. It is designed to run on a self-service kiosk, along the lines of the one pictured below.
Normally the kiosk would be equipped with
· A scanner to read borrower barcoded tickets or similar device.
· A coin acceptor
· A card swipe or chip-and-pin reader
· A receipt ticket printer.
The kiosk requires a PC running Windows as the base operating system.
In addition to the basic functions for receiving borrower payments, the system also allows for some “housekeeping” functions. These comprise two types
· On the kiosk, to perform test functions
· Within VubisSmart to provide an audit trail and controls over what has happened on the kiosk.
The application has been written as a Web based program, to run with a secure browser. Specific features require the use of the “SiteKiosk” secure browser ( see http://www.sitekiosk.com); and the runtime touch screen keyboard application from MountFocus. Of course, all the relevant software and hardware is installed by Infor on the kiosk as part of the configuration and installation.
Finally, the software has been designed to allow for comprehensive changes as to the screen design, so that the kiosk can be amended by the library to reflect the look and feel required for any library, for example by the extensive use of style sheets.
Note that Pay Stations are not a standard part of the Vubis Smart application. It requires a specific license and must be installed and activated separately. Please contact your account manager for pricing and installation information.
The simplest way of describing the functionality is by showing the main series of screens that will be seen by the borrower. It should be noted that the screens displayed represent a specific configuration and setup. Details of how the screens may be adjusted are described later on.
Firstly, it is useful to explain briefly how these initial screens are arrived at.
The Windows PC inside the kiosk is configured to automatically boot up with the “SiteKiosk” secure browser. In the event of a power fail etc, SiteKiosk will run up and present the initial login screen (as shown below).
Whilst SiteKiosk is typically meant to be a secure version of Internet Explorer, all the status bars, command icons and so on are turned OFF, with the result that only the functional screen part is seen. No control commands are available – users can only use the hyperlinks and so on embedded directly in the application. Indeed there is NO keyboard associated with the kiosk (at least on the outside!), and users must use a touchscreen keypad when such input is required (see below).
When SiteKiosk starts up, the “home page” displayed looks like the above, expecting a regular Vubis Smart staff login. Name and password are NOT a borrower’s but rather the application waits for a staff member to log in the kiosk. See section xxx for specific details.
The initial start screen simply waits for a borrower to scan their library ticket. The whole of this screen can be amended by the library (see section xxx for details). In this example the screen gives the borrower an overview of the processing stages, so that they know what to expect.
Please note that the pictures in the screen above are meant to display the actual kiosk, but at time of writing no pictures of the actual kiosk are available.
In general, each screen has an idea of a “main action” which is shown above in reverse video, and possibly a “sub-action”, configured to display in yellow.
This screen shows the password input screen – a touch screen keyboard is put onto the screen to allow users to enter their password.
The black circles appear as the user types to show that data IS being accepted. If Caps Lock (or the “user a to z” button) is touched, then the keyboard changes to show lower case letters.
This screen shows the amount owing in summary form. Full details of charges can be shown. Payment by cash or by credit card is selected by touching the screen at the relevant place as shown.
At this point the user is prompted to enter coins into the slot, as shown. Total paid and a running balance is displayed on the screen. Borrowers may touch the Finish button when they have run out of money, and of course the system will stop when they have paid in full.
In either case, they are then presented with the option to print a receipt.
In this particular case, the system warns the user that they have NOT fully paid all the outstanding charges – they have pressed Finish without paying the total amount.
See the system specification for credit card payments for fuller details. In brief, the user is automatically switched to the BucskNet remote server (in this case) and all processing is carried out on the remote session. The precise design of the screens to lead the borrower through the processing – to enter their card and PIN – is established by the library with BucksNet. Subsequent processing returns the borrower to the receipt printing stage.
This section describes the various errors and timeouts that can occur.
Although the system checks that a library ticket is or isn’t valid, it always proceeds to the PIN input stage. Ticket and PIN are always taken together – and if the card is invalid (e.g. a lost barcode) or the PIN invalid, then the system only ever prompts “invalid PIN”. We try to give NO clues if a ticket is lost or stolen and is randomly tried (although it is unlikely that someone would take a reader’s ticket and then try to pay their fines for them!).
After three attempts the following screen is shown.
The screen above is displayed if the borrower has no charges to pay. They may touch the screen to clear the display (or of course the screen will “time-out”).
In all situations, the screen will timeout after 60 seconds. Specific processing depends on the step that the user as got to. If no payment has been started, as such, then a 10 second countdown appears on the screen which can be interrupted by the borrower. For example –
Once a payment has been started, then the system will simply timeout. The borrower may not interrupt this, since we don’t wish to allow a user to walk away, thinking that they have paid, but allow another user to cancel a timeout and display their details etc.
Timing out will, of course, credit whatever has been paid to the borrower’s account.
Several special functions are provided. These are “run” by keying special commands in when the user barcode is expected. Of course, there is no keyboard normally with which to enter these commands, so “command” barcodes are provided to allow the commands to be scanned by the barcode scanner.
In order to provide a checkpoint in the audit trail, a special barcode can be entered at step 1 which simply tells the system that a staff member has emptied the cash box. (There is of course no way to tell whether they really HAVE done this, but it puts a marker in the audit trail (see below) to indicate that this has happened).
It is of course sensible for staff to check that the hardware (such as the coin acceptor) is correctly working, at intervals. A designated Test barcode is available for wanding. This automatically “pretends” that the notional borrower owes 10.00 and the staff member can deposit coins etc without actually updating the borrower database. (Credit card payments are NOT available, of course).
The transactions are logged in the audit trail as “test” transactions.
Individual coins are NOT debited from the borrower’s account until the completion of the transaction. There is therefore a small chance that there may be a system crash during the processing of a borrower’s session on the paystation.
The individual coins entered are, however, recorded against the borrower. When the borrower account payment screen is accessed, the system displays
That is it shows specific details of what was entered but not processed. Staff may choose to credit the borrower’s account or to discard the money (if for example) they have already refunded such payments (or to postpone the decision entirely!). Such conflicts MUST be resolved before any other payments can be expected.
There is, of course, still a possibility that the borrower entered a £1.00 coin but the system crashed before recording the payment. In this case, the audit trail can identify this. If the coin WAS accepted, then we would expect there to be £1.00 more in the cash box than is actually recorded by the system, and staff could legitimately refund the borrower.
(Of course, there IS still a technical hitch – suppose the power went off whilst the borrower was entering money – then ALL systems will be down and there is simply no way of validating what was logged by the system. Staff, as ever, must use their own judgement as to the validity or otherwise of a borrower’s claim to have lost money in the machine !)
Credit cards
Similar problems can potentially occur for credit card payments and this is fully discussed in the specification for credit card payments, elsewhere.
The layout of any receipts printed is defined in the file “receipt.txt” held in the “paystationhtml” folder.
For example
Date <date> <time>
Received
Amount owing : <owing>
Amount received : <amount>
Borrower card <cardcode>
With thanks
Specific data fields are enclosed in side <…> and may be one of
<date> <time> <owing> <amount> <cardcode>
Individual details of items paid for are NOT shown on the receipt.
Libraries may edit “receipt.txt” to any layout they wish (subject of course to the constraints of a narrow receipt printer).
Further detail
1. The receipt layout may be different for a Card payment from that for a Cash payment. The main reason for this is that a FEE may have been charged for using a credit card – in which case, the total may be displayed by the special field “<owing+fee>”,
2.
The filenames for the layouts are actually held in ^AFO(“PayStationHTML”,”receiptcash”) and ^AFO(“PayStationHTML”,”receiptcard”) respectively.
These may be edited on site as required to record the FULL pathname of the layout files.
It is possible to run a version of the pay stations without allowing for credit cards. This can be initiated by an option to the command which starts up the pay station application.
It may also be turned on at runtime by a special command to be entered at the pay station. This latter might be useful, if for example there is a hardware problem with the chip-and-pin card reader. (And it may also be turned back on).
If this option is turned on, then it can be seen that the workflow is slightly different. For example, the user selection as to whether to pay by cash or credit card is not required and this section is skipped. In fact, the system uses completely different screens for the most part; so that all functions can be carefully tailored to the precise environment. Of course, some of the screens will look identical (for example, the option to print a receipt or not) but technically they use different source code. (See the Configuration section for details).
(It should be noted that it is possible to “turn off” card payments for VubisSmart as a whole – for example, in the event of known system problems with the card service provider. In this case, the selection of the payment by credit card DOES nothing but the “view” of the screens is not automatically changed.)
In a similar fashion, it is also possible to tell the system that the printer is unavailable. This removes the final options to print or not print a receipt, with text message such as
Since fixing the printer would normally mean opening the unit, it is expected that the kiosk would be restarted. There is therefore no option to ‘restart’ the printer.
Here for example is the Start screen for the Coins only option
Which can be compared with the start screen in section 0.
The following screen effectively combines the initial cash or coin selection and the coin input screen.
See the help on AFO 491.
· Document control - Change History
|
Version |
Date |
Change description |
Author |
|
1.0 |
September 2006 |
creation (delivered as part of build 17 updates) |
|
|
|
|
|
|